Embedded hardware based system which provides real-time pre-trade risk assessments for multiple parties and method thereof

ABSTRACT

A risk assessment system and method are provided that may be implemented as an embedded hardware based system and method that provide real-time pre-trade risk assessments for multiple parties, in addition to real-time market data and trading connectivity to a variety of liquidity venues. The liquidity venues may include regulated exchanges, ECNs and other financial institutions listing securities, options, futures, commodities, foreign exchange and other financial instruments.

PRIORITY CLAIMS/RELATED APPLICATIONS

This application claims the benefit, under 35 USC 119(e) to and priorityunder 35 USC 120 to U.S. Provisional Patent Application Ser. No.61/414,832 filed Nov. 17, 2010 and entitled “Embedded Hardware BasedSystem Which Provides Real-Time Pre-Trade Risk Assessments For MultipleParties And Method Thereof', the entirety of which is incorporatedherein by reference.

FIELD

The disclosure relates generally to a system and method for assessingtrade risk for multiple parties and in particular to an embeddedhardware system for doing the same.

BACKGROUND

There are currently various systems that are commercially available tofinancial market participants and their clients which provide acombination of both pre and post trade risk assessments, real-timemarket data and also trading connectivity to numerous liquidity venueslisting financial instruments comprising of securities, options,futures, commodities and foreign exchange. The aim of such systems is toprovide financial market trading participants with the fastest availableelectronic market data and trading connectivity to liquidity venues,while also providing intra-day trading risk assessments for both theparticipant and also their own electronically connected trading clients.

Since the advent of electronic trading in the 1980's, the number ofelectronic liquidity venues around the globe has increased dramaticallyand has resulted a continuing rise in both market data and tradingvolumes. Since the 1990's greater market data and trading volumes havealso been exacerbated by an increase in what is termed Automated Trading(AT), whereby trading entities have utilised computer systems to listento market data streams and send automated orders to liquidity venuesbased upon pre-determined criteria. These increases in both liquidityvenues and market volumes have increased the trading opportunities forboth financial market participants and their clients alike. However as aconsequence, they have also led to an unceasing demand to reduce thetime latency involved in processing ever expanding market data streams,assessing pre and post trade risk and ultimately sending orders andreceiving trades from liquidity venues.

The ability to reduce the latency involved within the market data, riskand trading cycle increases the potential for competitive advantage forboth financial market participants and equally their end clients. Marketparticipants that combine the fastest access to liquidity venuereal-time market data, real-time risk assessment and also real-timetrading will be able to execute trades ahead of their market competitorsand ultimately will be more attractive to potential clients, due thelikely increase in profits that their higher performing systems willproduce. Conversely, the ability to provide pre-trade risk analysis on amore timely basis reduces the potential for market participants andtheir clients making a trading loss, as market risk exposure can be moreaccurately calculated and automated remedies enforced. Consequently, thecurrent market place surrounding electronic market data, risk assessmentand trading access, is an environment in which the majority ofcommercial solution providers are constantly seeking to reduce the timelatencies of their products to as near to zero as is technicallypossible.

To date, all companies making commercially available systems havewritten their software applications to operate on standardised computerhardware incorporating main components of a mother-board, hard-drive,memory, processor/s with a kernel, along with a standard recognisedoperating system, for example; Unix, Linux or Windows etc. Theapplications are normally written in standard software languages such asJava, C++ and any other C based languages. The software languagesthemselves add a given amount of latency to the applications as they arenot always specifically designed to provide the lowest functionallatency.

System latency reductions up until this point have therefore been gainedthrough increasing and/or refining any one of the main components; forexample, increasing computer memory or increasing the capacity and speedof the computer processor. Performance benefits have also been achievedby refining and tuning the software applications to operate at evergreater capacity and speeds.

However, while all of these remedies have helped to improve systemperformance over recent years, the ability to reduce latency to evencloser to zero is at present constrained by the current design incomputers that are comprised of multiple components and also the factthat current commercial software providers are only able to utilise thistype of industry standard hardware within their applications.

The major issue with current hardware is that each internal computercomponent including the operating system takes a specific amount of timelatency to communicate with other internal and external components viathe kernel. The communication between computer components is naturallyessential to the operation of current combined market data, trading andrisk applications. However, whether the delay occurs in reading a marketdata stream, analysing current risk or in sending orders to a liquidityvenue, the impact is that the overall combined latency of all thefunctions is increased while each component related to each businessfunction seeks to communicate with other components within the computermechanism via the internal Bus. This problem has also been exacerbatedby current transmission protocols such as TCP/IP and UDP which both addadditional latency to current commercially available systems. Inherentto this latency issue is also the current design of PCB's which have notbeen designed to have functional components situated within closeproximity so as to reduce the communication latency between each other.

The latency that each of the components adds to the market data, tradingand risk functions reduces the trading potential of the participant andconversely increases the risk to the participant of having over or underexposure to liquidity venues in terms of their overall trading strategy.As a consequence, all existing combined data, trading and riskapplication solutions suffer latency constraints from the design ofcurrent computer hardware which is potentially detrimental to both thetrading participant and also their clients.

It is therefore these latency issues that the disclosure below seeks toaddress by circumventing the issues of current hardware design. Thus, itis desirable to provide an embedded hardware based system which providesreal-time pre-trade risk assessments for multiple parties and methodthereof and it is to this end that the disclosure is directed.

BRIEF DESCRIPTION OF THE DRAWINGS

To help clarify the specific embodiments of the disclosure, diagramshave been appended to this application and the diagrams are intended todepict examples of the configuration of the system and method and, giventhe inherent adaptability of the system, the drawings should not beconsidered to limit the scope of the disclosure.

FIG. 1 a illustrates a risk assessment system;

FIG. 1 b is a high level system configuration diagram of animplementation of a risk assessment system that uses embedded moduleshousing the personalities containing the business process logic thatoperates within the risk assessment system;

FIG. 2 is an example of an implementation of a personality module of therisk assessment system in FIG. 1; and

FIG. 3 is a diagram that illustrates an example of a risk assessmentmethod that may be Implemented using the risk assessment system in FIG.1 that has a set of risk checks and processes that may be as performedby the personality module(s) within the risk assessment system.

DETAILED DESCRIPTION OF ONE OR MORE EMBODIMENTS

The disclosure is particularly applicable to a programmable logic device(PLD) microchip embedded risk assessment system and method and it is inthis context that the disclosure will be described. It will beappreciated, however, that the system and method has greater utilitysince the embedded system may be implemented in other architectures,with other embedded systems and implementations and/or in other mannersthan those disclosed below, but that which are within the scope of thedisclosure.

A risk assessment system and method are described below that may beimplemented in an embedded hardware based system and method thatprovides real-time pre-trade risk assessments for multiple parties, inaddition to real-time market data and trading connectivity to a varietyof liquidity venues comprising regulated exchanges, ElectronicCommunication Networks' (ECN's) and other financial institutions listingsecurities, options, futures, commodities, foreign exchange and otherfinancial instruments. The system and method, however, are not limitedto any particular liquidity venues since the risk assessment system andmethod may be used with any current liquidity venues as well as futureliquidity venues in which it is desirable to perform risk assessment.The system is designed for use by financial market participants andtheir clients who seek to use real-time market data streams to providereal-time pre-trade risk assessments in order to trade a variety offinancial instruments within multiple liquidity venues.

A typical example would be a participant who is trading equity productsacross multiple venues such as NASDAQ, NYSE, BATS and Direct Edge inNorth America. For each market venue, the system would provide a list oftradable stocks specific to that participant i.e. it would filter outstocks that the client would not be permitted to trade. The list ofavailable stocks would be sent to the system for the participant totrade according to his trading strategy. In the case of a Daily MarketCap (Traded Cash volume per day), the system would aggregate all tradesacross all venues and subtract their value from the Participantspre-defined Daily Market Cap up to the point that the limit was reached.It would then reject all orders that would breach the Daily Market Caplimit.

In one embodiment, the risk assessment system uses programmable logicdevices (PLDs) which are then programmed to provide real-time pre-traderisk assessments for multiple parties and also provide real-time marketdata and trading connectivity to a variety of liquidity venuescomprising regulated exchanges, ECN's and other financial institutionslisting securities, options, futures, commodities, foreign exchange andother financial instruments. The system reduces the latency or timedelay in providing each of the market data, trading and pre-trade riskfunctions for both market participants and their clients. In reducingmarket data latency, the system increases trading performance byreducing the time taken to send and receive orders from liquidityvenues, while also reducing the time taken to provide real-timeintra-day risk analysis which in turn helps to improve the financialintegrity of the liquidity venue, the market participant and also theirend clients.

The system resolves the latency constraints inherent within typicalcomputer designs that prevent financial market participants fromoperating combined market data, trading and risk functions and thesystem provides as close to zero latency as is possible. The limitingfactor in achieving zero latency being the operating frequency of thehardware application. The system differs from conventional systemsbecause the design is based upon an embedded system, such asProgrammable Logic Devices (PLDs) in one implementation, that containsall the major functional requirements of market data, trading and riskprogrammed directly into one or more embedded modules, such as the PLDs.In different implementations of the system, the embedded system modulesmay each be a Complex Programmable Logic Device (CPLD), FieldProgrammable Gate Arrays (FPGA), Field Programmable Object Arrays (FPOA)or an Application-Specific Integrated Circuit (ASIC) microchips andfinally on-chip microcontrollers with or without flash stored computercode. In one implementation, the embedded system modules are installeddirectly onto a surface, such as a printed circuit board (PCB), which isloaded into a single housing with a resilient power supply unit. Eachmodule that is part of the embedded system may have its own separateNetwork Interface Card (NIC) that allows communication with externalsystems.

The risk assessment system with the one or more modules has the marketdata, trading application and risk application written into the one ormore modules and the system is made up of a number of separate subsystems known as personalities. The separate sub-systems (thepersonalities) may include Service Module, Market Data, LiquidityVenues, Market Execution Participants, Clients, Log Auditor and Command& Control as shown in FIG. 1 which illustrates an example of one set ofthe different personalities. In the system, new personalities can beadded to the modules as may be required. In an implementation using thePLDs for the modules, the functions contained within each personalitymay be written into each PLD using VHDL (VHSIC (Very High SpeedIntegrated Circuits) Hardware Description Language). VHDL is a standardHardware Description Language specifically designed to describe thebehaviour of a physical circuit or microchip. Unlike traditionallanguages that operate sequentially, VHDL code operates concurrentlywhich as a consequence allows for vastly reduced operational latency asthe code is able to operate more functions simultaneously. Another ofthe advantages of using an embedded system, such as the PLDs, over atraditional hardware solution is that the modules containing eachpersonality are able to communicate with each other via a directconnection on the PCB as opposed to having to access other separatecomponents via the kernel and micro-processor that leads to a decreasein operational latency. The method implemented by the system reducesoperational latency by writing the functional Data, Trading and Riskapplication directly onto the embedded modules as opposed to writing asimilar application in software installed on a hard-drive as iscurrently the standard commercially available method. VHDL thereforeallows the solution to make use of the performance advantages offered bythe hardware architecture which is where the major latency reductionover current computer software solutions is derived.

FIG. 1 a illustrates a financial data system that has a risk assessmentsystem 100. The risk assessment system is capable of being coupled tovarious external systems to which the financial data system interactsand exchanges data. For example, the risk assessment system 100 iscapable of being coupled to one or more clients 90 a, . . . , 90 n whoare each users who use the risk assessments made by the system to engagein trades and the like, one or more market execution participants(Brokers or Prime Brokers) 91 a, . . . , 91 n who can execute a tradewhen it is made on one or more liquidity venues 92 a, . . . , 92 n. Oneor more market data sources 93 a, . . . , 93 n from which market data isextracted/retrieved/scraped, etc. is used for the risk assessment andother input/outputs 94 for the system.

The risk assessment system 100 supports various protocols used tocommunicate between the risk assessment system 100 and external systemsas shown in FIG. 1 a over a set of external communication links 90, . .. , 93. Each external communication link may support a TCP/IP,Multicast, Financial Information Exchange Protocol (FIX), ITCH, OUCH andother industry standard formats as operated by both liquidity venues andtrading participants. In addition the system can operate with differenttransport mechanisms including Ethernet connectivity and also switchedfabric systems such as InfiniBand. Furthermore, new communicationprotocols can also be easily added to the risk assessment system 100 toensure that the system meets current industry standards. The operatorcan thus use a variety of protocols to make a connection to the riskassessment system in order to access the functional system.

FIG. 1 b is a high level system configuration diagram of animplementation of a risk assessment system 100 (also known as afinancial data processing system) that uses embedded modules housing thepersonalities containing the business process logic that operates withinthe risk assessment system. The financial data processing system 100provides an integrated market data, trading and pre-trade risk functioninstalled on an embedded system, such as one or more PLDs, instead if atraditional software solution installed on a hard-drive. The purpose ofthe system is to provide the fastest financial industry standardfunctions related to reading and converting market data streams,providing trading functionality to liquidity venues, while alsoproviding pre-trade risk assessments for market participants and theirclients. The system provides a methodology advantage over traditionalsystems in that all the processes and risk checks (described in moredetail below) are programmed directly onto the embedded system whichallows faster analysis and trading throughput to liquidity venues.

The CPLD, FPGA or FPOA described above is an integrated microchipdesigned to be configured by the user after manufacturing. The firstembodiment of the system and method involves utilizing the FPGA toprovide market data, order management and pre-trade real-time risk froma programmable chip installed on a printed circuit board (PCB). A secondembodiment of the system and method utilizes FPOAs which can operate upto four times faster than standard FPGAs. A third embodiment of thesystem and method may utilize ASIC microchips to potentially provideeven greater latency reductions. The ASIC microchips would be designedin advance rather than being programmed or coded after manufacture, butwould provide the same market data, trading and pre-trade risk functionsas programmable CPLD's, FPGA or FPOA microchips.

The advantage of the embedded system module approach is that there isnone of the traditional latency delays associated with conventionalmarket data, trading and risk functions operating in a traditionalserver design made up of separate components of hard-disk, processor andmemory etc. By combining all three elements on embedded modules, thecommunication times between the three required functional elements(market data, trading & risk) are reduced to a minimum. Embedding theentire combined market data, risk and trading application on an embeddedsystem allows the operator to leverage operating speeds at least (n)times faster than current commercially available systems using standardhardware configurations wherein “n” is dependent upon the type ofembedded module utilized within the system. For example, currentcommercially available systems operate pre-trade risk checks with anapproximate latency of 250 Milliseconds (ms). The embedded device withPLDs, for example, can operate risk checks with a latency of less than 5Microseconds (us), i.e. approximately 5000 times faster.

The functional system containing the market data, trading and riskapplication logic is written directly to the embedded modules and ismade up of a number of separate sub systems known as personalities. Asshown in FIG. 1, the personalities may include a service module (1 a),one or more market data modules (4 d) (with four market data modulesexisting in the example implementation of the risk assessment system inFIG. 1), one or more liquidity venue modules (5 e) (with four marketdata modules existing in the example implementation of the riskassessment system in FIG. 1), one or more market execution participantmodules (7 g) (with two modules existing in the example implementationof the risk assessment system in FIG. 1), one or more client modules (3c) (with two modules existing in the example implementation of the riskassessment system in FIG. 1), a log auditor module (8 h), a core module(6 f) and a command & control module (9 i). Additional personalities canbe added into the system as may be required. The data Transport withinthe risk assessment system over a set of internal links 101 that arecontrolled by the VHDL code which is significantly faster than standardapplications using current internal transport protocols. This againreduces operational latency within all the business logic functions asall of the personalities are able to communicate with each other at muchfaster speeds.

The personalities within the system each provide a certain aspect offunctional logic as required within the overall market data, trading andrisk system. In certain embodiments of the system, each personality maybe assigned its own dedicated hardware microchip that in turncommunicates with other personalities on separate microchips. The systemmay also contain a ‘hot standby’ chip that can back-up any one of theother personalities should they suffer an internal failure. Eachpersonality is configured to poll other personalities within the systemand in the event of failure, the hot standby chip immediately replacesthe personality of the failed module. In another embodiment of thesystem, the system may use a single ASIC chip to house all thefunctional logic of the personalities and the ASIC chip would bereplicated on the PCB to provide resilience in the event of primary ASICapplication failure.

In the embodiments of the system that uses the PLDs, the approachbenefits from having all the functional personalities installed on thesame printed circuit board (PCB) without the need to communicate via akernel, as is the case with current commercially available solutions.This design approach reduces the latency involved in the variouspersonalities (required functions) communicating with each other. Theembodiment of the system that uses a single ASIC chip installed on asingle PCB would contain all the personalities and the associatedfunctional logic so likely provides the lowest time latency and all thefunctional logic contained on a single ASIC chip would negate the needfor separate personalities to communicate across the PCB and CoreModule. This in turn would allow for much faster processing internallywithin the single ASIC chip and would provide faster market data streamconversion, faster risk assessments and ultimately faster orderthroughput to liquidity venues.

The personalities within the risk assessment system each provide acertain aspect of functional logic as required within the overall marketdata, trading and risk system. Each personality within the riskassessment system is assigned its own dedicated module that in turncommunicates with other personalities on separate modules as shown inFIG. 1 b. The design of each personality module is shown in more detailin FIG. 2 which shows the internal configuration of the personalitymodule and is described in more detail below.

Upon start-up, the system 100 as shown in FIG. 1 b is controlled by theService Module personality (1 a) which is the master control process andcontrols the start-up of the other available personalities. Once thepower up is completed, the Service Module personality 1 a will seek toinitiate connections to all available personalities within the riskassessment system 100. In the event that the Service Module personality1 a fails, it will also be polled by the other available personalitiesand subsequently shut down and re-started on the hot spare (2 b). Due tothe system being embedded, each Personality module is available for usealmost instantly upon system power up, unlike traditional systemswhereby the hardware must go through boot-up cycle The Hot Sparepersonality module (2 b) is a personality designed to replicate anyother personality in the event of primary personality failure. Again dueto the fact that the personality is embedded on the module, in the eventof a primary personality failure the new Back-up personality on theModule (2 b) will be available for use in approximately 2 seconds postthe analysis of the primary personality failure.

The system is designed so that each personality within the riskassessment system 100 polls the other available personalities to checktheir integrity using the internal links 101. In the event that acertain personality is deemed to have suffered an error, the personalityis cut-off by the other remaining personalities in order to maintainoverall system integrity. The personality that is deemed to have failedis then restarted on the ‘Hot Spare’ personality (2 b). The system isable to achieve this because the application code for each personalityincluding spare personalities is held within the firmware. This meansthat the hot standby (2 b) contains a spare personality for each of theprimary personalities within its memory. The polling process betweenprimary personalities facilitates a constant health check for the entireRisk application ensuring that failed personalities are quickly shutdown and replaced by back-up personalities held in the Hot Standby (b2).There can be multiple instances of the hot spare personalities 2 b toprovide resilience throughout the system.

The command and control module (9 i) has a primary function that is toallow control and configuration of the other personalities within therisk assessment system 100. Within command and control module (9 i) isan X86 interface (over the internal link 101 with the command andcontrol module 9 i that allows an external operator to interact with therisk assessment system from their own computer in order to program andconfigure existing personalities. The programming may includeconfiguring client personalities with pre-determined risk criteria,Market Execution participants with risk criteria or simply configuringnew or existing Liquidity Venue and Market Data personalities. Examplesof which can include: Instrument, Amount (Tradable number of giveninstrument), Price Deviation from market (93), Total value per order(consideration), Daily market Cap (Daily Cash Volume limit) and Value AtRisk (VAR). The command and control module (9 i) is backed up by thespare module 2 b in the event of primary failure. An example of usingthe X86 interface to re-program an existing personality would be if aclient was being given a new Cash Limit for daily trading. In thisinstance, the Market Participant controlling the client would use theX86 to alter the (RSK 11) component as seen in FIG. 3 by means of theComponent Ethernet component (1PM) as shown in FIG. 2.

The market data module (4 d) personality (several are shown in FIG. 1 b)allows for the collection of real-time market data streams from avariety of liquidity venues such as regulated exchanges, ECN's and otherfinancial institutions listing securities, options, futures,commodities, foreign exchange and other financial instruments. As perother commercially available systems, the system converts the datastreams into a single readable format that can be then utilised fortrading and risk assessment purposes. The market data module 4 d iscapable of reading all of the current industry standard data formatssuch as ITCH, OUCH, and FIX and in addition it can be easily configuredto read new market data streams. The data can be comprised of multiplelevels to provide the operator with a view of the depth of the marketfor any given instrument. The market data personality also communicatesinternally within the risk assessment system with the client module(s) 3c and the market execution participant module(s) 7 g. The market datamodule 4 d is backed up by spare module 2 b in the event of primaryfailure.

The Liquidity Venue personality module(s) (5 e) allow the clientmodule(s) 3 c and the market execution participant module(s) 7 g tointeract with the actual liquidity venue for the purposes of sendingtrade orders and for receiving notifications of order completions—bothfull and partial. Essentially, the module (5 e) is coded directly to theApplication Program Interface (API) of each required liquidity venue.The Liquidity Venues allows market participants to code directly totheir core systems for the purpose of sending electronic orders.Depending upon the specific rules of the liquidity venue, this APIinterface will allow for the sending of orders and the reception oftrade notifications from each venue. It is this personality (5 e) thatallows either the client module(s) 3 c or the market executionparticipant module(s) 7 g to submit orders to each specific liquidityvenue and which also updates them with details of any order completionsi.e. when a trade order message is generated by the client(s) 3 c, themessage will contain the ID of the Liquidity Venue and accordingly theorder will be submitted by the appropriate 5 e personality. The same 5 epersonality will also provide 3 c with the details of any completedtrade orders related to the original order instruction. The liquidityvenue personality also communicates internally within the riskassessment system with the Client personality for the purposes ofproviding intra-day pre-trade risk assessment and acknowledgment oforders and completions. In addition, the liquidity venue module 5 e alsoreceives market data streams via 4 d for the purposes of providingintra-day risk assessments. Multiple instances of Liquidity venuepersonalities can be configured according to the trading participantsand the client's requirements. 5 e would be backed up by 2 b in theevent of failure within the primary 5 e component.

Each client personality module (3 c) contains all the risk criteriarelevant to a particular trading participant. A system administratorwould normally utilise the command and control module 9 i to configurethe client's risk profile within the appropriate Market ExecutionParticipant (7 g) personality. For example, each client module 3 c maybe programmed with a daily Cash figure which would relate to the totalamount in a given currency that a client would be allowed to trade at aliquidity venue. Every time that an order is sent to a liquidity venuethat results in a trade, the value of the trade would be subtracted fromthe daily cash figure to leave a remaining daily amount of cash totrade. This figure would be used to verify the validity of allsubsequent orders in that each new order would have its consideration(price×volume) checked against the remaining cash figure. In anyinstance where the value of the new order was greater than the remainingcash figure that order would be rejected and not sent to the liquidityvenue. A message would however be sent to both the client and MarketParticipant informing them of the limit breach. The reason for thisprocess is that there is a direct relationship between specific clientsand market execution participants and by programming market executionparticipant module 7 g with the profile of the client it ensures thatthere is a direct link between the client and the appropriate marketexecution participant.

As a result, each client module 3 c receives its risk criteria by meansof a ‘Start of Day’ (SOD) file which would be forwarded by the MarketExecution Participant module 7 g upon pre-market opening. Post marketclosure, the client module 3 c will send an End Of Day (EOD) file to themarket execution participant module 7 g which will comprise the riskprofile of the client at market close. The EOD file would be passed backto the client in readiness for the trading cycles of other liquidityvenues based potentially in different geographical areas and listingdifferent asset classes. This process ensures that the client's overallrisk exposure is maintained across asset classes and across time zones.An example setting of a client's risk profile would be a limitation ofthe amount of daily volume (a Total Daily Cash Figure Limit) that aclient is permitted to trade or alternatively a limitation on thespecific stocks that the particular client is permitted to trade.

In the instance of a Daily Cash Figure Limit being in existence, theconsideration (Volume×Price) of every trade that was executed at eithera single or a multiple of liquidity venues would be aggregated toproduce a real-time Cash figure total. This figure would be subtractedfrom the pre-programmed Daily Cash Limit figure to produce a figurecontaining the remaining cash limit available to trade on that day. Allsubsequent orders would thus be pre-validated by ascertaining their cashvalue (Quantity×Price) and checking to see if this cash amount was lessthan the remaining daily cash value figure. If the cash value figure wasless than the daily figure, the order would be validated for entry tothe market, however if the value was less than the remaining dailyfigure, the order would be denied and the send or of the order would besent a message informing them of the reason for the order rejection.

The actual client utilising the personality would connect their owntrading system by means of the in-built NIC card, PCIe or InfiniBandwithin the module housing the client personality 3 c. This would allowfor the free flow of trading messages and acknowledgments from theliquidity venue via the client personality 3 c. The client personality 3c communicates with the market data personality(ies) 4 d in order tocheck pre-trade risk criteria such as whether the order was withincurrent liquidity venue price limits. If the order was deemed as withinacceptable limits, it would be forwarded to the appropriate liquidityvenue. Each client module 3 c is capable of providing all of theindustry standard pre-trade risk checks and analysis including OrderQuantity, Price, Price×Quantity, Average Daily Volume, Total DailyVolume, Value At Risk (VAR) and % from last traded price. In addition,each client module 3 c also provides a market surveillance checkconcerning orders of the same direction, price, side, price andquantity. Each client module 3 c also contains functionality concerningrestricted lists specifically concerning stocks or instruments that agiven client is for whatever the reason prevented from trading by theMarket Execution Participant (7 g) or liquidity venue (5 e).

While the system contains all the usual industry standard risk checks,it nevertheless differs from traditional pre-trade risk systems in thatit keeps its own record of a trading participants liquidity venue ordersand in doing so it alone decides upon the existence of orders at theliquidity venue, rather than the traditional approach of waiting for anelectronic confirmation from the venue to prove the orders existence.This design approach means that the system prevents a user from sendingmultiple orders to market in the belief that none of them have so farexecuted. The system essentially utilizes a ‘what if’ process to preventrealisation of a bad position or trade by assuming that any order sentto a liquidity venue is already complete, thus avoiding over-exposurewithin a given instrument. The reason for this approach is that, by itsdesign, the system 100 seeks to significantly reduce the latency withinthe market data, trading and risk cycle. It is therefore foreseen thatthere may be occasions where the System will suffer delays whileliquidity venues process and acknowledge the trade orders generatedwithin the System. If the system was programmed like existing pre-traderisk systems it would need to wait for the sequential orderacknowledgments from each liquidity venue prior to sending anysubsequent orders, updates or indeed cancellations. Despite the Systembeing able to process market data streams in advance of other competingsystems, much of the latency advantage inherent within the System wouldbe lost while it waits for liquidity venues to respond to its previoustrade messages such as an order entry, cancel or amendment. Consequentlythe system allows both the client and the execution participant to sendnew order instructions to a liquidity venue despite the previousacknowledgement having not yet been received. This is done on the basisthat it assumes that the previous order will ultimately be acknowledgedand accordingly it has already updated the risk profile of both theclient and the market execution participant to allow submission of newinstructions to the liquidity venue i.e. it has already debited orcredited the trading accounts. This allows both the client and themarket execution participant to continually take advantage of fastermarket data streams without having to continually wait for the liquidityvenue trading system to catch up.

In the event that a previous market order is not acknowledged, theclient 3 c and the market execution participant 7 g cannot trade overtheir pre-determined cash figure because the system already assumes thatthe trade has occurred. In the rare case that a trade message was notacknowledged by a liquidity venue, the system 100 is designed to allowmanual intervention so that the missing trade message can be struck andall the risk profiles updated accordingly. The Client personality (3 c)is backed up by 2 b in the event of primary failure.

The market execution personality (7 g) is similar in nature to theclient module 3 c. The market execution personality 7 g would normallycontain the details of the broker operating the risk assessment systemwhose liquidity venue membership the risk assessment system would use tosend orders. As such it would contain the risk profile of the ExecutionParticipant through whose membership the clients would be sending ordersto the liquidity venue. However, in addition, it also contains the SODrisk profile of any related client who would be using the marketexecution participant to access a liquidity venue. The SOD file would besent to the appropriate client personality 3 c pre market-open each day.In addition, the market execution personality 7 g would also receive theEOD file from each client post-market closure at each liquidity venue.The EOD file would be passed back to the client personality at the startof trading phases at other liquidity venues. This would ensure that theclients overall risk profile is always accurate across all liquidityvenues and time-zones. The market execution personalit(ies) 7 g can bereplicated by 2 b in the event of primary failure.

The Log Audit personality (8 h) is responsible for keeping records ofall communications both to and from all personalities within the riskassessment system. This includes all records of submitted trade ordersby both the client personality and also the market executionpersonality. It also keeps records of all liquidity venue tradeexecutions both full and partial. All records are time stamped to thenearest Nano Second so that in the event of an investigation the Audittrail will provide a sequential view of all actions and responses bothwithin the risk assessment system but also by external connections suchas the client, market execution personality and also the liquidityvenue. The Log Audit personality also keeps time stamped records of allconfiguration changes by the system administrator using the command andcontrol personality. This is to ensure that the configuration of therisk assessment system can be audited and that any changes relating tofor example a client's risk profile can be fully recorded and checkedagainst the pre-determined risk profile of the said client. In the eventof failure within the primary (8 h) it would be backed up by 2 b whichwould replicate its functions within the risk assessment system.

The Core Module 6 f provides physical connections to each of thepersonalities within the risk assessment system. Like all thepersonalities the core module is installed directly on the PCB. The coremodule contains a number of pins in its physical design that allow thepersonalities to connect directly to it via the PCB. The Core Modulethus provides the physical interconnections that allow personalities toconnect with other personalities within the System design. The corepersonality can be replicated by 2 b in the event of primary failure.

In FIG. 2, the configuration of a hardware personality module within therisk assessment system 100 is shown in more detail. The module is madeup of a Gigabit Ethernet PHY component (1PM) which is used tocommunicate externally with the personality for the purposes ofinstalling and updating the configuration of the personality code. Forexample, this could be for the purposes of changing individual risklimits as previously detailed. The component (1PM) communicates with aMAC interface component 2PM which is used for the purposes oftranslating between external IP (remote) addresses and the internal MACaddress on the Ethernet interface (1PM). The MAC address is used for allinternal communication across the personality.

The module may also have a central processing component 5PM that may be,for example a FPGA/FPOA, such as commercially available from XILINX,which is the type of FPGA card being used for the purposes of thisdiagram. The 5PM component is where the main body of the personalitylogic is held. The module may also have an SRAM (3PM) that is a memorycomponent used by the 5PM component. The components of the module areconnected together as shown in FIG. 2.

The module may also have an environmental monitoring component 4PM thatis used to monitor the physical health of the personality module by themaster command and control module 9 i (MCP) as shown in FIG. 1 b. The4PM component allows for power, heat and the logic of the personality inFIG. 2 to be checked and monitored by the MCP and allows for the MCP todecide whether the personality should be shut down and re-instantiatedon a Hot Back-Up personality as shown in FIG. 1 b. The module may alsohave a local power supply component (6PM) that is the power input to thePersonality. The health of the power supply is checked and monitored bythe 4PM component. The module may also have a DDR3 RAM Module (7PM) thatis a memory component within the personality that contains the maininternal memory of the personality. It has a higher frequency rate thanthe 3PM component and also a higher capacity.

FIG. 3 is a diagram showing the Main Risk Functions of the Personalitieswithin the PCB. In the example shown in FIG. 3, the risk assessmentsystem 100 connecting to the London Stock Exchange Test Trading System(CDS) with an onward connection to a Client's RISK simulator is shown.The main risk functions are initiated each day with the Start of Dayfile (SOD) (RSK1) which contains the risk limits and the stockrestrictions for each client or market participant. The SOD is passed tothe Preload File (RSK2) in order to create a preload file for either theclient or the market participant. RSK2 is also sent a static data listfrom the Market Data Server (RSK3) which contains a list of the tradableInstruments at a particular Liquidity Venue. Combined together, theStatic Data and Restriction lists form the preload File which is usedfor distribution across the personalities housed in the risk assessmentsystem. The RSK 2 component sends the pre-load file firstly to the DayCap (RSK11) component, then to the Order Cap (RSK12) and subsequently tothe Restricted List (RSK13), Instrument List (RSK14) and finally to theRIC Code component (RSK15).

The day cap component RSK 11 provides the risk check on the daily cashamount that a client or market participant is allowed to trade on agiven day. The RSK 12 Component provides the risk check on the cashamount per order that can be sent i.e. the physical upper limit on thevalue of a single trade order. The RSK 13 component is the record of therestricted list of instruments per client/per market. In essence it is alist of instruments that for a variety or reasons the client is notpermitted to trade. These restrictions could be implemented by theliquidity venue or the market participant.

RSK 14 is a list of tradable instruments that either a client or marketparticipant is permitted to trade. RSK 15 is a list of RIC codes thatare used to identify instruments across different exchanges. The codesare unique industry standard identifiers that help clarify that orderssent to market are targeted at the correct instrument. It can be seentherefore that the 5 components listed above all provide elements ofrisk filters that are required for the opening order sent to a LiquidityVenue.

The RSK3 component also provides all intra-day price updates (Price,Volume etc) pertaining to the tradable instrument list as sent as partof the pre-load file. From the RSK3 component real-time intraday marketdata information is sent to the Parse and Filter Component (RSK4). RSK4is responsible for submitting the updated price information to the RSK5components which ensure that each price update is attributed to thecorrect RIC code and ultimately the correct tradable instrument. If aclient is submitting an entirely new Market Opening order, RSK5 willforward the order details to RSK6 in order to check the opening orderprice against the static data and also to the RSK19 component to ensurethat the new order is within the allowable positive price range (%) andconversely to the RSK 20 component to check whether it is in theallowable negative % range. In addition it will also update the RSK 7and RSK21 Status components to show the status of the new ordersubmission.

For orders sent after the market open phase and also for any amendmentsto existing orders, the RSK5 component sends market data information tothe Trade Price component (RSK 8). The RSK8 component in turns ensuresthat any new or amended orders are within the % limits of the currentmarket price (A liquidity Venue trading requirement).RSK8 thereforesends the updates to the Trade Price component (RSK16), the Dynamicnegative % component (RSK17) and finally the Dynamic positive %component (RSK18).

Along with the Static % check (RSK9) and the Dynamic % check (RSK10)orders are checked against the current market data stream for dynamicpositive % changes (RSK17), dynamic negative % changes (RSK18) andagainst the last Trade Price (RSK16).

The Lock Flag Indicator RSK 22 is used to check whether the liquidityvenue has suspended any tradable instruments intra-day. Any instrumentsthat have been issued with a lock flag will not allow users (clients ormarket participants) to submit new orders to the market for the giveninstrument (identified by RIC code).

The combined output from all the components listed above allows thePre-Risks Checks Components (RSK24) to determine whether new andsubsequent orders are valid and can be sent to the liquidity venue ofchoice. Each component therefore checks the order against its own limitswithin the preload file and also against the intra-day file for thegiven customer or market participant. If each component confirms thatthe order is valid (in terms of the pre-determined limits) the RSK 24component will send the order to the liquidity venue (in the attachedFIG. 3—The London Stock Exchange test trading system) and will finallyupdate the client trading simulator (RSK23).

The advantages of utilizing risk assessment systems as opposed totraditional software are multiple. Firstly the latency involved inreading multiple market data streams will be vastly reduced which willlead to additional latency benefits in the speed and accuracy of bothrisk analysis and also trading performance. In addition, the ability toreceive market data at faster speeds allows the operator to make moreinformed decisions relating to their trading strategy. This alsomanifests itself in being able to analyze risk positions moreaccurately, as the faster market data interpretations provide a morerelevant picture of risk exposure both for the market participant butalso the end client. Secondly, by improving the speed and accuracy ofmarket data and risk analysis, trading participants can utilize theirtrading capital more efficiently and with less risk of intra-dayexposure. It is predicted that the risk assessment system should be ableto achieve a total latency figure for all of these market data, tradingconnectivity and risk analysis of sub-millisecond (Ms) excludingexternal transport protocols. From a pure electronic system designperspective, the system offers additional benefits in that it is farsmaller in size the current commercial computer systems and as aconsequence uses far less real-estate and also power in order tofunction. This reduced foot-print has additional benefits in that theSystem requires far less cooling than traditional systems thus reducingthe carbon footprint still further.

While the foregoing has been with reference to a particular embodimentof the invention, it will be appreciated by those skilled in the artthat changes in this embodiment may be made without departing from theprinciples and spirit of the disclosure, the scope of which is definedby the appended claims.

1. An embedded risk assessment system, comprising: a surface; at leastone client personality module, at least one market participantpersonality module, at least one liquidity venue personality module andat least one market data personality module each installed on thesurface and electrically connected to each other; the at least oneclient personality module having a set of risk data for a particularclient; the at least one market participant personality module storing aset of risk data for a broker in a liquidity venue; the at least oneliquidity venue personality module allowing the at least one clientpersonality module and the at least one market participant personalitymodule to interact with the liquidity venue to send a trade and receivenotifications of a completed trade; the at least one market datapersonality module gathering data about a particular market; and the atleast one client personality module, at least one market participantpersonality module and at least one liquidity venue personality moduleperforming pre-trade risk assessment for the client with reducedlatency.
 2. The system of claim 1 further comprising a hot sparepersonality module installed on the surface that stores a set of codefor each of the client personality module, the market participantpersonality module, the liquidity venue personality module and themarket data personality module so that the hot spare personality moduleis swappable for any of the client personality module, the marketparticipant personality module, the liquidity venue personality moduleand the market data personality module if those personality modulesfail.
 3. The system of claim 1, wherein the surface is a printed circuitboard.
 4. The system of claim 3, wherein each of the client personalitymodule, the market participant personality module, the liquidity venuepersonality module and the market data personality module is one of aprogrammable logic device, a Complex Programmable Logic Device, a FieldProgrammable Gate Array, a Field Programmable Object Array and anApplication-Specific Integrated Circuit.
 5. The system of claim 3,wherein the client personality module, the market participantpersonality module, the liquidity venue personality module and themarket data personality module are all on an Application-SpecificIntegrated Circuit.
 6. The system of claim 1 further comprising acommand and control personality module that perform start-up of theembedded risk assessment system.
 7. The system of claim 6, wherein eachof the command and control personality module, client personalitymodule, the market participant personality module, the liquidity venuepersonality module and the market data personality module polls theother personality modules to determine if a personality module hasfailed.
 8. The system of claim 1, wherein the market data personalitymodule collects real-time data from one or more liquidity venues andconverts the real-time data from one or more liquidity venues intocommon format market data.
 9. The system of claim 1, wherein the clientpersonality module performs a market surveillance check for orders inone of the same direction, price, side, price and quantity as an orderof the client.
 10. The system of claim 1, wherein the liquidity venue isone of a regulated exchange, an ECN and other financial institutionslisting securities, options, futures, commodities, foreign exchange andother financial instruments.
 11. The system of claim 1, wherein at leastone client personality module controls one or more trades of the clientbased on the risk data for the particular client.
 12. The system ofclaim 1, wherein at least one client personality module ensuresregulatory compliance of the client by controlling access to multipleliquidity venues.
 13. A method for risk assessment using an embeddedhardware system, the embedded hardware system having at least one clientpersonality module, at least one market participant personality module,at least one liquidity venue personality module and at least one marketdata personality module each installed on a surface and electricallyconnected to each other, the method comprising: storing, in a clientpersonality module, a set of risk data for a particular client; storing,in a market participant personality module, a set of risk data for abroker in a liquidity venue; interacting, using a liquidity venuepersonality module, between at least one client personality module andthe at least one market participant personality module with theliquidity venue to send a trade and receive notifications of a completedtrade; gathering, using a market data personality module, data about aparticular market; and performing, using the client personality module,the market participant personality module and the one liquidity venuepersonality module, pre-trade risk assessment for the client withreduced latency.
 14. The method of claim 13 further comprising swappinga hot spare personality module installed on the surface into theembedded hardware system if the client personality module, the marketparticipant personality module, the liquidity venue personality moduleand the market data personality module fail.
 15. The method of claim 13further comprising performing, using a command and control personalitymodule, start-up of the embedded risk assessment system.
 16. The methodof claim 13 further comprising polling, by the client personalitymodule, the market participant personality module and the one liquidityvenue personality module, the other personality modules to determine ifa personality module has failed.
 17. The method of claim 13 furthercomprising collecting, by the market data personality module, real-timedata from one or more liquidity venues and converting the real-time datafrom one or more liquidity venues into common format market data. 18.The method of claim 13 further comprising performing, by the clientpersonality module, a market surveillance check for orders in one of thesame direction, price, side, price and quantity as an order of theclient.
 19. The method of claim 13 further comprising controlling, bythe client personality module, one or more trades of the client based onthe risk data for the particular client.
 20. The method of claim 13further comprising ensuring, by the client personality module,regulatory compliance of the client by controlling access to multipleliquidity venues.